1. Field of the Invention
Exemplary embodiments of the present invention relate to management of timeouts for transactions, and more particularly, to management of timeouts for transactions initiated by threads on shared-memory multiprocessor systems.
2. Description of Background
Multiprocessor or multi-core systems contain multiple processors (also referred to herein as CPUs) within a single machine that can execute multiple processes, or multiple threads within a single process, simultaneously in a manner known as parallel computing. Parallel computing operates on the principle that larger problems can often be divided into smaller ones that may be solved concurrently. In general, because different threads and processes can be carried out literally simultaneously on different processors, multiprocessor systems execute multiple processes or threads faster than conventional single processor systems such as personal computers that execute programs sequentially. Shared memory multiprocessor systems offer a common physical memory address space that all processors can access. Multiple processes therein, or multiple threads within a process, can communicate through shared variables in memory which allow the processes to read or write to the same memory location in the computer system.
It is expected that, as shared memory multiprocessor systems continue to develop, the number of processors (and thus, the number of hardware threads that can concurrently execute) will continue to increase. Nevertheless, the increase in the number of threads that may be executed simultaneously creates problems with synchronizing data shared among the threads. Thus, the degree to which processes can be executed in parallel depends, in part, on the extent to which they compete for exclusive access to shared memory resources, as threads may attempt to access the same resources at the same time in a manner that is difficult to manage efficiently. In multithreading computer systems, particularly those that include multi-core processors or multiple processors, it is often necessary for concurrently executing processes to arbitrate entry into a critical section of a program. This is often because a program executing in the critical section is accessing a resource that may only be accessed exclusively and must exclude all other programs from simultaneous access. Therefore, careful control of the variables that are modified inside and outside the critical section is required.
Typically, each thread uses the programming construct of a lock at the entry and exit of a critical section to ensure exclusive use and enable synchronization. A lock allows one thread to take control of a shared resource and prevent other threads from reading or writing it until that resource is unlocked. One thread will successfully lock the shared resource, while other threads will be blocked—that is, waiting in idle status until the variable or shared resource is unlocked again. The thread holding the lock is free to execute the critical section, and to unlock the data when it is finished.
Lock-based resource protection causes substantial synchronization issues that utilize system resources and can greatly degrade system scalability and relative efficiency. The cost of using locks is the overhead of lock operations incurred on each thread (for example, the memory space allocated for locks, the processor time to initialize and destroy locks, and the time for acquiring or releasing locks) and the decrease in scalability due to lock contentions among threads (that is, where threads attempt to acquire locks held by other threads). Because only one thread can enter its critical section when locks compete, lock contention poses a significant limit on the maximum useful number of processors in a system. Furthermore, the more locks being used, the more overhead associated with the usage. Compared to non-lock operations, lock operations, such as compare-and-swap and memory serialization, are slow, typically requiring tens or hundreds of clock cycles on typical processors. Thus, even in situations where lock contention does not occur, lock operations will incur a high number of processor cycles.